home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9610 / 000041_owner-urn-ietf _Sun Oct 13 02:32:21 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  4KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id CAA28362 for urn-ietf-out; Sun, 13 Oct 1996 02:32:21 -0400
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id CAA28357 for <urn-ietf@services.bunyip.com>; Sun, 13 Oct 1996 02:32:14 -0400
  3. Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA22597  (mail destined for urn-ietf@services.bunyip.com); Sun, 13 Oct 96 02:31:41 -0400
  5. Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <15369(5)>; Sat, 12 Oct 1996 23:31:37 PDT
  6. Received: by golden.parc.xerox.com id <2765>; Sat, 12 Oct 1996 23:31:26 PDT
  7. To: urn-ietf@bunyip.com
  8. Subject: [URN] suggestions for "A Framework for the Assignment and Resolution ..."
  9. From: Larry Masinter <masinter@parc.xerox.com>
  10. Message-Id: <96Oct12.233126pdt."2765"@golden.parc.xerox.com>
  11. Date: Sat, 12 Oct 1996 23:31:26 PDT
  12. Sender: owner-urn-ietf@services.bunyip.com
  13. Precedence: bulk
  14. Reply-To: Larry Masinter <masinter@parc.xerox.com>
  15. Errors-To: owner-urn-ietf@bunyip.com
  16.  
  17. We were asked to keep the discussion of 'NAPTR vs PURL' offline, and
  18. keep the mailing list focused on the framework document.
  19.  
  20. The Framework document needs references; clearly, after such a very
  21. long period of discussions of what URNs are and are not, it would help
  22. to distinguish this framework from, say, the approaches of
  23.  
  24. Winograd, "Stable Network File URLs as a Mechanism for Uniform
  25. Naming", 1993: <http://www.saintjoe.edu/URI/stanf.html>
  26.  
  27. Kahn & Wilensky, "A Framework for Distributed Digital Object
  28. Services", cnri.dlib/tn95-01,
  29. <http://www.cnri.reston.va.us/home/cstr/arch/k-w.html>
  30.  
  31. or even mention the background in 
  32.  
  33. Arms et al, "Uniform Resource Names", D-Lib Magazine, February 1996,
  34. <http://www.dlib.org/dlib/february96/02arms.html>
  35.  
  36. even though almost all of the authors of that article are listed in
  37. the framework acknowledgements.
  38.  
  39. The framework document has a section labeled "Authority Over Name
  40. Strings", but the section doesn't actually go into any details about
  41. the difficult elements of name migration. It says "Rules for
  42. individual namespaces are determined by the owners of the namespace
  43. before they are registered in the NID registry", but this kind of
  44. analysis omits the important element of what omits any mention of the
  45. difficult problems that arise when namespace owners themselves
  46. disappear.
  47.  
  48. This is a rather old song, but I will sing it again:
  49. draft-daigle-urnframework-00.txt is inadequate because it does not
  50. deal with any of the issues of administration & security & migration &
  51. longevity that are the entire motivation for having 'URNs' instead of
  52. 'URLs'.
  53.  
  54. You might argue that those issues are social issues and not technical
  55. ones, and that this is an engineering group, not a social policy
  56. group. However, engineering solutions are often advanced as solutions
  57. to social policy questions. For example, for better or worse, several
  58. mechanisms for 'key recovery' have been advanced as an engineering
  59. solution to the social policy question of balancing between police
  60. investigative capabilities and personal privacy.
  61.  
  62. Those same mechanisms might be used, for example, as a way of allowing
  63. the 'owner' of a name to have the exclusive right to assign metadata
  64. or location information by signing such assignments with the owner's
  65. private key, but also allowing the infrastructure to recover when an
  66. owner disappears or is unresponsive by resorting to some form of key
  67. recovery or delegation.
  68.  
  69. I don't think the framework needs to specify the mechanism by which an
  70. name's authority might assert a relationship between the name and
  71. various pieces of metadata and location information, but the nature of
  72. the assertions made, the roles of third parties in either verifying
  73. the assertions or providing clients the means of verifying, the ways
  74. in which authority can either migrate to different organizations or be
  75. supplanted by the moral equivalent of "trusted librarians" needs to be
  76. addressed in far more detail than appears here.
  77.  
  78. Regards,
  79.  
  80. Larry